fix(extensions): set aside an unusable ledger row instead of failing the file - #1061

Review of #1061 found three real defects, one of them destructive.

1. A ledger can hold a preserved row AND a runnable row under the same id —
   a rollback produces exactly that. `removeExtension` computed both
   independently and let both act, so one call did both things in both
   directions: clearing the set-aside row uninstalled the working extension
   and `rm -rf`'d its bundle, and uninstalling the working extension silently
   destroyed the row we have the least right to destroy. The reviewer
   reproduced both on disk.

   Ambiguity between two different objects is not resolvable by a precedence
   rule, so they are now two operations: `removeExtension` touches only
   runnable rows, `removeQuarantinedExtension` only preserved ones, with its
   own IPC channel and preload method. The quarantine remover never deletes a
   bundle — the path would have to come from fields that failed validation,
   and once the row is gone the sweep collects the directory on its own.

2. The sweep's preserved-bundle protection had NO test. Deleting the line
   left all 206 tests passing. The new tests drive the REAL
   `sweepAbandonedInstallDirectories`, not the helper: covering the helper
   alone is what let the protection go untested.

3. Protection was narrower than the rationale claimed. It was keyed on an
   exact path built from the raw row's `installation.id`, which evaporates in
   the one case the feature exists for: a future build that RESHAPES
   `installation` writes rows this build both rejects and cannot locate, so a
   single rollback-and-relaunch deleted the newer build's bundles. Protection
   is now keyed on the extension ID — validated independently, and the one
   level of `.bundles/<id>/<generation>` the sweep itself walks — so it needs
   no guess about what a future generation looks like. The old flat
   `EXTENSIONS_DIR/<id>` path went with it: the sweep never considers that
   level, so it protected nothing while a test asserted it did.

   The cost is stated in the code: an id that is both preserved and runnable
   keeps its superseded generations until the preserved row is removed. A
   stale directory beats deleting code a rolled-forward build needs.

   The remaining limit is stated rather than papered over: a row whose id does
   not validate protects nothing, because we cannot name a directory we have
   no trustworthy name for, and guessing is how the sweep deletes an unrelated
   tree.

Mutation-checked: dropping the sweep protection fails 2, and each direction of
the remove collision fails 1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>